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REPLACING OLD APPLICATIONS 


Many information systems executives feel trapped by 
the past—they have hundreds or thousands of old applica- 
tion programs and data files that they would love to re- 
place. But with a backlog of perhaps two years’ worth of 
new work already in the queue, they see no way of replac- 
ing these “dinosaur programs. This need not be the case 
any longer. Data management systems (and their fourth 
generation languages), application generators, and applica- 
tion packages now make replacement of many old applica- 
tions possible and practical. It is time to establish ‘a 
planned replacement program.’ (An executive summary is 


on page 16.) 


Livibe Trust Company is a = major 
money center bank with headquarters in 
New York City. It is the 16th largest com- 
mercial bank in the U.S., according to For- 
tune magazine. It has assets of $18.2 bil- 
lion and operates in 18 other countries. 
For many years, Irving Trust has used an 
account analysis system to keep track of 
the types of transactions made by the 
bank’s customers. This batch system pro- 
duces monthly reports listing the volumes 
of the various kinds of transactions by pro- 
duct line and by customer. Analysts use 
these reports to study the profitability of 
the bank’s services. | | 
The system was written in COBOL in the 
mid-1960s. Since then, it has migrated 


from IBM’s disk operating system to its 
present operating environment, MVS, with- 
out changing much. In its monthly run, it 
manipulates large volumes of data; this 
run requires six hours on an IBM 3033. 

In 1980, data processing was asked if 
the system could be substantially updated. 
The system was not serving the bank’s 
needs adequately, and it had become dif- 
ficult to maintain. For one thing, it col- 
lected data from many other systems—de- 
mand deposit accounting, letter of credit, 
electronic funds transfer, and so on. Each 
time one of these services was changed, or 
a new service was offered, a new program 
had to be written for the account analysis 
system, to extract the relevant data. 
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The account analysis system had been operat- 
ing on a monthly batch basis. The users wanted 


it changed to an on-line information system, 


through which they could obtain ad hoc infor- 
mation, as well as receive regular reports. 


Data processing was willing to update the sys- 


tem if the users could fully and accurately de- 
scribe their needs. But the users were not sure 
what they wanted. They knew what they did not 
like about the old system, but they did not know 


all the features they would like in the new sys- — 


tem. 

After some effort trying to create specifica- 
tions for the new system, the users decided on an 
alternate approach. They went to the bank’s 
newly formed Information Center and asked if 
it’s people would help them develop the new 
system. 


The Information Center shares an IBM. 3033 | 


computer with the software development area. 
The center seeks to encourage users to do some 


of their own computing. As an aid, it offers FO- 


cus™, a data management system from Informa- 
tion Builders, Inc., of New York City (Reference 
1), as well as other end-user products. 

Since the traditional approach for replacing 
the account analysis system (by first creating de- 
tailed specifications) had not succeeded, the peo- 
ple at the Information Center agreed to help the 
users replace the system themselves. Several FO- 
CUS consultants were assigned to assist the user 
team, and the users were given terminals for on- 
line access to FOCUS. 

The users were also told about two utilities— 
developed by data processing and offered by the 
Information Center—that would help them. One 
is a data delivery system that allows users to re- 
quest data from a production computer. The 
data is transferred to the development computer 
within one day’s time. The other is a data distri- 
bution system that allows users to output large 
amounts of print data to a disk system. Such re- 
ports are then produced once a day. 


The project took about 15 months to com- 


plete, with the team working part-time on it. 
During the first four to five months, the team re- 
created the old system, using FOCUS, and incor- 
porated new features they knew they wanted. 
When they added a new feature, they allowed 


nate 


other people in the inolhean to test it. This — 
process enabled the team to create a system that — 
was well received, but it also caused develop- os 


ment to take longer than expected. | 

Conversion to the new system was accom- 
plished in three phases. In the first phase, the 
two systems were run in parallel, with the old 
system generating a magnetic tape that was used 
to transfer data to the FOCUS database. This 
phase lasted about three months. 

In the second phase, parallel processing con- 
tinued, but the tape and card input was loaded 
directly into the FOCUS system. This phase mee | 
another three months. 

In the third phase, the old system was discon- 
tinued. 

The users hope to update the input process 
further, phasing out magnetic tapes and cards. 
The new system will then draw its inputs di- 
rectly from the production databases. At this 
point, however, the manager of the Information 


_ Center is not sure whether tapes and cards can 


be completely eliminated. 

Before undertaking development of the new 
account analysis system, the user team had de- 
veloped several small systems, using Information _ 
Center tools. In effect, they had served as a 
small application development team within their 
own department. When they began developing 
this new system, however, they were surprised 
how much more difficult the development effort 
was. Although the coding was easy, they ran into” 
many unexpected procedures—procedures com- 
mon to most data processing projects. For exam- 
ple, the new system needed data security fea- 
tures, which these users had not anticipated. In 
addition, the system may eventually lead to di- 
rect customer billing for services. So it had to be 
scrutinized by internal auditors and data process- 
ing. The users had no strong arguments against 
these requirements, they just had not foreseen 
them. 

Also, due to the large number of transactions 
handled by the system, the users found testing 
more difficult than they had expected. In order 
to reduce processing time, they divide the data- 
base into many smaller databases—creating 
twelve monthly transaction databases, a product — 
code database, and a customer account database. 
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Co-ordinating these databases and writing proce- 
dures to update them was also harder than they 
had anticipated. 

Even so, the development methodology the 
users employed was the only appropriate ap- 
proach for replacing the old system, because 
they did not know what they wanted until they 
had experimented with new features. And they 
created—and are maintaining—a system that now 
fills their needs. 

Will the Information Center encourage other 
users to replace old applications in this manner? 
The answer is: Yes for small systems; probably 
not for systems with large databases, although 
the decision may rest with the users. The new 
monthly batch run is not as efficient as data 
processing would like, due to the large number 
of transactions processed. On the other hand, the 
system is well suited for ad hoc reporting. And it 
is leading to new and better uses of the data by 
other departments in the bank. 


General Mills, Inc. 


General Mills, Inc., with headquarters in Min- 
neapolis, Minnesota, is a diversified corporation 
with entities in five different industries. They 
started out in the milling business, and in recent 
years the company has diversified into other in- 
dustries, such as toys, specialty retailing, fashion, 
and restaurants. The company is the 80th largest 
corporation in the U.S., according to Fortune 
magazine, with annual sales of over $5.3 billion. 

A few years ago, the consumer foods group 
decided that several of their old financial appli- 
cations needed updating. In addition, two other 
corporate accounting systems required replacing. 
These old systems were originally written for 
their Honeywell computer, in the late 1960s, or 
their Burroughs computer, in the 1970s. Some of 
these old systems had been updated, but others 
had not. Therefore, additional code conversion 
was required. These systems had become com- 
plex and required continual maintenance to stay 
abreast of the changing business environment 
and new regulatory agency requirements. 

Their approach was to study the marketplace, 
choose the most appropriate software, and then 
obtain the necessary hardware—which turned 
out to be an IBM system. As Snyders briefly de- 


EDP ANALYZER, MARCH, 1983 


scribes in Reference 2, the company did not 
want to expand its data processing staff, even for 
so large a project; yet they wanted a tailored sys- 
tem. To meet both needs, they acquired both the 
Corporate General Ledger™ package and the 
Generation Five™ application generator from 
American Management Systems (AMS), of Ar- 
lington, Virginia. 

The software. Several of AMS’ products have 
been written using their Generation Five appli- 
cation generator. Purchasers of these packages 
automatically obtain the generator to modify, 
enhance, and maintain the packages. 


Generation Five contains: (1) an on-line screen 
generator, (2) database management facilities, (3) 
a procedural language that employs accounting 
terms (such as post and summarize), (4) an ac- 
counting-oriented report writer, and (5) pre- 
coded routines for common accounting func- 
tions. Also, it provides a development methodol- 
ogy, giving all applications the same structure. 


For more information about AMS products, 
see Reference 3. 

The application. The basis for General Mills’ 
new integrated system would be the Corporate 


_ General Ledger package. Modifications and ex- 
~ tensions would be written in Generation Five. 


The general ledger package had been written us- 
ing Generation Five, so such changes would fit 
in with the existing package structure and code. 
General Mills liked this approach of being able 
to make modifications within the ‘envelope’ of 
the package. 


The entire replacement project—replacing all 
nine systems—took fifteen months, including 
three months of live parallel processing between 
the old and new systems. The project could have 
taken less time, but the company did not want 
to rush conversion. 


Conversion was a joint effort between General 
Mills and AMS. The General Mills team con- 
sisted of one person from data processing, four 
from consumer foods, and one from corporate 
accounting. This team concentrated on system 
design (performed with AMS personnel), data 
conversion, and system testing. The corporate 
accounting team member wrote several custom 
reports using the AMS report writers. 


At the same time, AMS had a team of analyst- 
programmers tailoring the general ledger pack- 
age, using Generation Five. The General Mills 
team observed this coding process carefully, so 
that they could take over maintenance and en- 
hancement when the project was completed. 


If the company had opted to redo the old sys- 
tems using COBOL, the conversion would have 
become a multi-year effort, costing over a mil- 
lion dollars, the manager of the project told us— 
because the lengthy time requirement would 
have been complicated by personnel turnover 
and the changing business environment. Use of 
Generation Five reduced the complexity of the 
effort and speeded up development. 


On the question of data conversion, the Gen- 
eral Mills team decided not to convert their 
master and ledger data directly. However, they 
did want to edit and validate all data coming 
from the old systems. Therefore, they wrote one- 
time programs to convert the old systems’ data 
into the package’s ‘add table maintenance trans- 
action’ format. The transactions were then pro- 
cessed through the package’s table maintenance 
routines. Historical ledgers were converted to 
financial statement transactions and validated 
against the new validation tables, creating new 
ledgers. 


This one-time validation process served a 
number of useful purposes. First, it tested the 
logic in the package’s file maintenance routine. 
Second, it identified discrepancies in the old data 
and new structure. And third, it uncovered sev- 
eral data problems in the old systems. 


To simplify processing, General Mills uses the 
package’s standard file format. All ledgers— 
whether actual, budget, allocation, or consoli- 
dated—use the common format. For special re- 
porting, or interfacing with other applications, 
they use Generation Five to generate a file with 
the needed special structure, based on the stan- 
dard file format. 


A recommendation General Mills has for com- 
panies considering using application generators 
is—do a thorough job of planning. On the one 

hand, application generators may be appropriate 
for some applications, but not others. Genera- 
tion Five is written specifically for financial ap- 


plications. It may not be appropriate for inven- 
tory control applications, we were told. 

On the other hand, the use of a generator can 
be abused, unless standard practices are estab- 
lished at the outset. It may provide flexibility 
that can be misused—it may offer several ways to 
perform a function, yet there is probably one 
best way. Together, General Mills and AMS de- 
cided on appropriate refinements for the new fi- 
nancial systems and subsequent use of Genera- 
tion Five. 

General Mills’ use of the general ledger pack- 
age and Generation Five has provided several 
benefits to data processing and the users. For 
data processing, the large conversion was com- 
pleted without hiring more staff. In addition, the 
new system has eliminated the formerly complex 
‘closing’ process, at the end of each month and 
fiscal year. Data processing now only executes a 
pre-defined schedule, mounts tapes, and distrib- 
utes reports. And finally, the new process is ef- 
ficient. Since application features are integrated, 
less complex, and more streamlined, they require 
less processing time. | 

To the users’ benefit, the new system ‘belongs’ 
to them. They perform the maintenance. 
Changes generally are handled via master table 
maintenance, not re-coding. Enhancements re- 
quire using Generation Five, which the users 
have learned. In all, they manage the use of the 
integrated system, and are responsible for keep- 
ing it up-to-date. Product updates are supplied 
by AMS with an installation guide. 

All in all, General Mills is pleased with the 
way they replaced their important, yet obsolete, 
financial systems. 


The penalty of easy migration 


‘Easy migration’—it’s the catch-word of all 
computer manufacturers. It means installing new 
equipment and, at the same time, allowing exist- 
ing programs to continue running. As we say in 
the U.S., “It’s like apple pie, motherhood, and 
baseball.”” How could anyone be against it? 

Well, for years, companies have discovered 
that easy migration has a negative side as well— 
it chains them to the past. Although the hard- 
ware is updated gradually, the software is not; it 
stays with the old technology. Vendors make it 
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easy to move onward and upward to more pow- 
erful, newer computers by allowing you to drag 
all of your old programs along with you—not to 
mention your keypunches, card readers, and 
other old peripherals these old programs may re- 
quire. There are companies running programs on 
their IBM 3033 which were originally written for 
their IBM 1401 computer—carried forward from 
the 1960s! 

The common retort is, “Why replace these 
applications? They may be old, but they’re run- 
ning!” The answer is: they are probably costing 
your company more than you think. 

These old programs have caught up with the 
companies that have long ignored them. Mainte- 
nance in many organizations is 70% of the pro- 
gramming effort. And the programs that are 
hardest to maintain generally are the ones that 
have been around the longest. They have little 
documentation, and most of that is practically 
useless, because it is so out-of-date. They are 
written in old languages, which many young pro- 
grammers (who are often assigned maintenance 
work) do not know. And it is just plain hard to 
find programmers willing to work on such dis- 
couraging ‘messes.’ 

Since these old programs are difficult to main- 
tain, they do not get maintained as they should; 
therefore, they’ do not meet users’ changing 
needs. Users often do not request changes, be- 
cause they know it is a long and tedious process 
to get such changes made. So users are often un- 
happy with these old systems, because they have 
so little control over them. 

These old programs are burdensome to users 
in another way—they use out-of-date procedures. 
Since they are mainly batch oriented, often using 
card input, turnaround is slow—usually measured 
in days, not minutes. Each program generally 
has its own file, and combining data from several 
files, to create ad hoc reports interactively, is 
usually out of the question. So, while the current 
computer may be up-to-date, the users may still 
be filling in keypunch forms by hand and waiting 
a day or more for the results. Thus, these old 
programs are probably making users less produc- 
tive than they could be with updated versions. 

Information systems management often wants 
to replace these old applications, but they feel 
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trapped. Rewriting these old programs in, say, 
COBOL would take even more resources away 
from ‘more important’ new work. 

But there are now products available that 
make replacement of old programs practical, 
relatively easy, and cost effective. It is possible 
to start ‘an early retirement program’ for these 
old systems. Since the software has not been im- 
proved as it migrated, a concerted effort will be 
needed to start this replacement program, in 
companies with huge numbers of old programs. 
But the benefits can far out-weigh the difficul- 
ties, as we will point out throughout the remain- 
der of this report. 

Application development is currently under- 
going a major change. The old, tried-and-true 
method of exhaustive systems analysis coupled 
with ‘hand coding’ is giving way to prototyping 
and partially automated programming. Applica- 
tion and program generators and data manage- 
ment systems, which automate much of the cod- 
ing, can be used for most business applications. 
They can decrease application development time 
enormously. Many programmers resist these pro- 
ducts, saying that they take away the ‘art’ and 
fun of programming. But it is becoming clear 
that hand-coding of many business applications 
is no longer cost-effective. Replacing old appli- 
cations with these new products now appears 
practical. 

In addition, application packages have ma- 
tured to the point where they can be used to re- 
place some old in-house applications, and per- 
haps bring about standardization at the same 
time. 


Three replacement approaches 


So we see three types of products that can be 
used to replace old hand-coded applications: 
Data management systems, application and pro- 
gram generators, and application packages. Fol- 
lowing are considerations for using these ap- 
proaches. | 


Using data management systems 


Data management systems (DMS) contain ap- 
plication development tools based around a da- 
tabase management system. They generally con- 


_ tain ‘a fourth generation language’ —meaning, a 


non-procedural programming language—with 
which end users can create applications and set 
up data files. Complex business applications, 
with links to, say, COBOL subroutines, can also 
be created using these systems; however, pro- 
gramming expertise is generally needed for these 
uses. 

Most articles about DMS discuss using them to 
create new applications—but these products are 
equally useful for replacing old applications. To 
illustrate this approach, we talked with Mary 
Rich, an independent consultant in El Segundo, 
California, about her use of RAMIS II™, a data 
management system from Mathematica Corp. of 
Princeton, New Jersey (Reference 4). 

Rich has been using RAMIS for five years, and 
has helped a number of companies replace old 
_ business applications with RAMIS and RAMIS II 
applications. Rich told us about a recent project 
which is typical of the old applications she has 
replaced. 

The application was an installment loan track- 
ing and billing system—a major application in 
this organization. It was originally written in CoO- 
BOL in the early 1970s. When a loan was ap- 
proved, people in the company’s accounting de- 
partment filled in forms by hand to initiate the 
payments schedule. These forms were 
keypunched and the resulting cards were merged 
by hand into the punched card payment file. The 
payment cards in turn were used to update a 
master tape for the daily billing run. A second 
file of cards contained the loan information. But 
the cards themselves caused innumerable prob- 
lems—cards got lost or were duplicated by mis- 
take or were mutilated by the card reader. 

This system interfaced with a credit system, 
which authorized credit for the loans. The credit 
system had been written in RAMIS II a few years 
ago. The people in accounting noticed that it 
was interactive and much easier to use than 
their old COBOL-based batch system. They asked 
that their installment loan system be replaced 
with an interactive RAMIS II system. 

The request was approved and three people 
were put on the project—the maintenance pro- 
grammer, a new, inexperienced programmer, 
and Rich. All coding was done in RAMIS II, ex- 
cept for developing the input display screens. 


These were programmed in COBOL using IBM’s 
Display Management System. At the time, RAMIS 
II did not have a screen formatter; now it does. 

The conversion of the basic, pre-specified sys- 
tem took about four work-months, during a six 
month time period. This included coding and de- 
bugging. However, that was only part of the 
conversion. As Rich pointed out to us, in all the 
conversions she has worked on, they have always 
added enhancements—changes the users had 
wanted for years. 3 

For example, the specifications for the new 
system did not describe interfaces to other sys- 
tems. In the old system, as payments were re- 
ceived, forms were filled out by hand, 
keypunched, and that data was used to update 
the general ledger. Also, several important func- 
tions had not been automated, such as calculat- 
ing pre-payments and issuing bills for delinquent 
payments. Users- wanted to fix these problems. 
And some of the major changes required restruc- 
turing the database as well; this happened four 
times. Since RAMIS II allows iterative develop- 
ment, these new sub-systems were added by first 
prototyping them, then allowing the users to use 
them for a short while, and then adjusting them 
until they were suitable. 

Adding missing functions, and relating them 
to existing functions, adds quite a bit of time to 
a conversion project, said Rich. So, while coding 
in RAMIS II, or a similar language, takes very lit- 
tle time, figuring out how to add new elements 
does take some time. But in the end, the users 
have a much better system. 

The conversion took longer than had been ex- 
pected for two other reasons: (1) all three pro- 
grammers worked on the project only part-time, 
and (2) two of the programmers had no previous 
experience with RAMIS II, so they were being 
trained on the job. 

The new system was based on a structured 
analysis of the functions performed by the old 
system, rather than a duplication of the old code 
in a new language. This approach was fortunate, 
Rich told us, because they discovered during the 
re-write that some of the calculations performed 
in the old system were wrong—and they had al- 
ways been wrong! The two systems were run in 
parallel for three months, and whenever a dis- 
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crepancy was uncovered, it was the old system 
that turned out to be incorrect. 

Rich said she has seen this happen before; RA- 
MIS II systems tend to have fewer errors in them 
than the systems they replace because the RAMIS 
II programs are simpler. It is not unusual, she 
said, for a 100-line RAMIS II program to replace 
a 6000-line COBOL program. So the simplicity of 
DMS programs not only speeds up coding but also 
leads to more accurate systems. 

Data conversion was very simple, because it 
was performed automatically by RAMIS II. RAMIS 
II read the tape and cards as transaction files and 
converted them into a pre-defined RAMIS II data- 
base, containing some 65,000 records. Restruc- 
turing the database was equally easy. 

The organization has received an important 
benefit from the new system—quick response to 
needed changes. Due to the recent volatile na- 
ture of the financial community, new types of 
loans have occurred literally overnight. In one 
rush case, the project team was able to make the 
needed changes to 40 RAMIS II programs in only 
four hours. Rich commented that it would have 
taken longer than that just to re-compile the 
equivalent COBOL programs! 

Users are happier with the system, and it con- 
tinues to grow. More uses are being found for it, 
so enhancements are continually being re- 
quested. Even with this increased number of re- 
quests, there is less total maintenance on the sys- 
tem, because it contains fewer lines of code, has 
more validation and control features, and _ is 
more accurate. 

In other conversions, Rich has encountered a 
few data file conversion problems. These occur 
only when the old files do not contain valid data 
or are not well documented. When converting 
from another database management system, the 
files usually must be converted from the former 
DBMS structure to a sequential format, before 
being read into the RAMIS II database as transac- 
tions. 

Rich also pointed out a feature of RAMIS II 
that is a significant aid in any conversion—to de- 
fine production system files and certain other 
DBMS files as ‘external’ files, and then use these 
with the RAMIS II reporting and data extraction 
language. For example, it allows programmers 
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to: (1) extract data from production files for test- 
ing, (2) produce the same set of reports from the 
new and old files for verification, and (3) quickly 
research problems in the data or in the code. 

Rich recommended using a DMS for all busi- 
ness applications except those that require real- 
time updating, multiple terminal updating, or 
very high volume. Applications especially suit- 
able for DMS are those subject to rapid changes 
(as in a regulatory environment) or where the 
need for ad hoc reporting is high, as in personnel 
or budgeting systems. 

She also recommended that new RAMIS II pro- 
grammers spend time doing system analysis 
work, before they begin coding (although not 
the exhaustive systems analysis needed when ap- 
plications are going to be hand-coded). Experi- 
enced RAMIS II programmers can perform analy- 
sis while prototyping, but inexperienced pro- 
grammers can get themselves into problems if 
they forego analysis, thinking that prototyping 
makes this unnecessary. 


Using application generators 


Application generators are being hailed as the 
next step in application development tools, fol- 
lowing high level languages, such as COBOL. 
This may be true, but only if the chosen product 
matches the application closely. Some of today’s 
application generators are aimed at specific 
types of applications; they make development of 
such programs faster and easier, but they will 
not do the same for all applications. An example 
is generators for financial applications; they usu- 
ally would not be appropriate for creating (say) 
market research systems. 

When the generator does not closely fit the 
application, programmers will revert to their old 
coding methods, to circumvent the product's 
limitations. And the company will end up with a 
hybrid application that was not much faster to 


develop nor very easy to maintain. So matching 


the generator to the application is necessary for 
realizing productivity gains. 

As Stewart discusses in Reference 5, there are 
two types of applications generators. Program 
generators create source code, yielding stand- 
alone programs. Application generators require 
that a run-time portion of the generator be used 


to run the application programs; they do not 
produce stand-alone code. The distinction may 
or may not matter. If the system produces source 
code, statements can be modified directly, with- 
out using the generator. However, systems that 
depend on a run-time module may run faster, 
says Stewart. Both types generally require pro- 
gramming expertise. | 

In a presentation at the National Computer 
Conference last year, Waldrop (Reference 6) dis- 
cussed the pros and cons of a financial applica- 
tion generator that his company used. 

On the benefits side, he said, several of the 
product’s features contributed to the team’s abil- 
ity to finish the large project almost on time. 

First, the product had a table-driven architec- 
ture. This significantly speeded up development, 
because all programs could draw on these tables. 
Changes usually needed to be made only to ta- 
bles, not to all of the affected programs. 


Second, the generator enforced a structured — 


methodology and standards for coding and data 
names. These, in turn, encouraged the use of 
common code. 

Third, since the generator was designed for 
financial applications, a number of routines 
based on common accounting functions contrib- 
uted significantly to faster development. Such 
functions as ‘reject-batch’ and ‘reject-document’ 
did not need to be hand-coded, for instance. 

Fourth, the generator’s automatic transaction 
suspense file—where transactions are stored until 
validated—eased the requirements for complex 
coding for posting transactions to the master file. 

Fifth, the generator required only one set of 
code for processing data in either batch or on- 


line modes. 


And sixth, the screen generator allowed the 
company to create the on-line system with pro- 
grammers who had not had prior tele-processing 
system experience. Since the application re- 
quired 53 screen formats, the screen generator 
contributed notably to speeding development. 

The company also ran into some unexpected 
problems—usually caused by unrecognized limi- 
tations in the product. To name a few, the pro- 
duct used a non-standard file access method, it 
did not provide the ability to create interactive 
display screens on-line (only input-only or out- 


put-only screens), and there were constraints on 
the number of data elements in a control table 
record. | 


Since the team had not used the generator 
previously, they did not design the system with 
the generator’s capabilities and limitations in 
mind. Thus, when design issues arose, only two 
(unsatisfactory) solutions were possible. One, the 
programmers could resort to coding the routine 
in COBOL; this introduced extra complexity into 
the system. Or two, the generator was used; this 
produced a less efficient solution. 


Despite these problems, the company was 
able to write 285 programs in about three 
months time, with twenty-five people at the 
peak point. A tribute to the generator, Waldrop 
stressed. 


One point stands out. Today's generators are 
not as flexible as the languages programmers are 
accustomed to using. Therefore, to make most 
efficient use of a generator, system designers 
must keep the product’s capabilities in mind. 


Using application packages 


We talked with the people at McCormack 
and Dodge Corporation, of Needham Heights, 
Massachusetts (Reference 7), about their experi- 
ences with companies that have replaced old ap- 
plications with one of their packages. 


They told us they have noticed two differences 
between users who are replacing a manual sys- 
tem and those replacing an old, automated sys- 
tem. Users replacing a manual system are gener- 
ally more fearful of any new system—they are 
afraid they will lose their jobs or they will not be 
able to cope with the new work environment. 
Users who are already working with an au- 
tomated system are generally more accepting of 
change. 


Second, users replacing old, automated sys- 
tems are usually more willing to compromise on 
features. They will forego some desired features 
in return for getting a new system more quickly. 
They are more realistic in their demands. They 
generally do expect, however, that a schedule be 
drawn up for adding missing features. McCor- 
mack and Dodge recommends that no changes 
be made directly to a package; such enhance- 
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ments should be added through external rou- 
tines. 

Usually it is the users, not information systems 
people, who urge investigating packages. They 
are upset that an old application no longer 
meets their needs, and they do not want to wait 
in a multi-year backlog queue for in-house de- 
velopment. If the information systems depart- 
ment agrees to consider purchasing an applica- 
tion package, McCormack and Dodge recom- 
mends setting up an evaluation team of about 
four people, representing both users and the de- 
partment. 

The first task of the team is to study the cur- 
rent operation and decide what functions the 
new system should perform. The team should 
question whether the existing procedures and 
output are necessary, or whether they could (or 
should) be changed. Work flow changes are of- 
ten necessary when installing a package, the 
company told us, so the question of whether 
users are willing to change the way they work is 
an important issue when considering packages. 

With a list of necessary and desirable require- 
ments, the team can begin looking at packages. 
A package that meets 80% of all requirements— 
plus all of the necessary requirements—should be 
considered a good fit. 

If the company chooses a package that can be 
customized, the next step is learning how to ‘tai- 
lor the package to their needs. All McCormack 
and Dodge packages use a control file, which 
contains the package’s various options. In order 
to understand the available options, McCormack 
and Dodge recommends that the evaluation 
team attend their one-week training school. 

During this week, attendees are taught the de- 
tails of the package, and they are given the as- 
signment of setting up a ‘dummy corporation’ 
and implementing various types of options. At- 
tendees from one organization are kept together 
as a team. They are encouraged to set up a 
dummy corporation that operates as their real 
company operates, so that when they finish the 
training class, they will have tested many of the 
options they believe they will want. 

Following the week’s training, most purchas- 
ers feel confident to tailor a package on their 
own. McCormack and Dodge provides a 
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‘hotline’ service, and evaluation team members 
often call and ask about implementing specific 
options. And, at times, users request a one-day 
on-site evaluation by a McCormack and Dodge 
consultant. But, generally, evaluation teams han- 
dle the installation on their own. 

Installation typically has four phases. In the 
first phase, the team creates the control file by 
selecting the options they want. They then run 
the package against a ‘sample’ corporation, sup- 
plied with each package. This step ensures that 
the package operates correctly in their operating 
environment. 

Second, they substitute company files for the 
sample corporation's files, in a test mode. Gener- 
ally, files need to be converted to the package’s 
file format. McCormack and Dodge recommends 
this be done by running the current files through 
the package as input transactions. This process 
not only converts the data into the proper for- 
mat but it also identifies problems—incomplete 
records, inconsistent data, etc. Package docu- 
mentation helps users. perform this conversion 
step. 

Third, the old and new systems are run in par- 
allel. 

And fourth, the company converts totally to 
the new system. Of course, users need to be in- 
volved in the process, to ensure that they change 
their operating procedures as the conversion 
moves through these phases. 

In the financial area especially, we found nu- 
merous ‘tailorable’ packages. With financial con- 
siderations changing so often, due to the more 
volatile business climate and government regula- 
tions, such packages may be a suitable answer 
for replacing many old, and probably hard-to- 
maintain, application systems. 


Replacement program considerations 


Given that the stockpile of old applications 
has become burdensome, and that a replacement 
program is needed, what problems will informa- 
tion systems management face when it initiates 
its “old application replacement’ program? 


Programmers will resist the new methods. It ap- 
pears that programmers and information system 
managers are not the ones pushing for “fourth 
generation software.’ Most prefer to stay with 


the procedural languages with which they are fa- 
miliar. It is generally the users who are encour- 


aging information systems departments to install. 


application generators, data management sys- 


tems, and application packages, we have been 


told. So, yes, management will face programmer 
resistance. | 

Programmers say that using these new pro- 
gramming tools requires less skill and knowl- 
edge, so that they (the programmers) will have 
less value in the market place. And they contend 
that these automated tools will take the creativ- 
ity out of their jobs, turning them into mere cod- 
ers. , _* 

Due to the reluctance of programmers to 
abandon their procedural languages, the job of 
replacing old applications using these new tools 
may fall to the enthusiastic, and discontented, 
users. However, this may not be the wisest 
choice for replacing all systems, especially the 
large ones. There are numerous non-obvious re- 
quirements for many large application systems 
(such as security, audit, and interfacing with 
other applications). End users may not know 
about such considerations, and their systems will 
most likely be lacking in these aspects. So re- 
placement of old applications probably should 
not be left entirely up to end users. 

Most programmers dislike maintenance work, 
because it disrupts new, more exciting projects 
on which they would prefer to work. To help 
overcome this negative attitude toward mainte- 
nance work, management could use a planned 
replacement program as a new opportunity—to 
train new and willing programmers on fourth 
generation languages, while reducing the main- 
tenance burden at the same time. 

_ Experienced programmers are not likely to ea- 
gerly accept this new educational opportunity. 
However, some employees in other departments, 
as well as new, younger programmers, may be 
interested in working with users and in learning 
a fourth-generation language. A conversion pro- 
ject would provide some business training as 
well, because these programmers would be 
spending less time on coding and more time on 
understanding applications. 

_ So a project to replace old applications by us- 
ing new tools and prototype development tech- 
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niques can provide a way of training a new gen- 
eration of programmers, while reducing the ap- 
plication maintenance burden. But it probably 
will not convert many long-time programmers to 
using more automated tools. 


The new programs will be inefficient. Some peo- 
ple contend that programs created by applica- 
tion generators are inefficient to run. In some 
cases this is true, says James Martin in his book, 
Application Development Without Programmers 
(Reference 8), especially where the generator 
creates source code which must be compiled. 
But in other cases, the generated code is more 
efficient than most hand-coded routines, because 
it is in assembly language or highly optimized 
code. And it may take less time to compile than 
hand-written code, if it contains large blocks of 
pre-compiled code. 

However, says Martin, this argument is spe- 
cious. Only 2% of the business applications in 
most organizations use 50% of the machine cy- 
cles. And 50% of the applications use only 2% of 
the machine cycles. For this latter 50% of the 
programs, programmer productivity is far more 
important than run-time efficiency. Hand coding 
of most business applications is just not cost-jus- 
tified any longer, he contends. 7 


Replacement will take longer than planned. 
When we began our research for this report, we 
started with a few assumptions. One was that 
since application generators and data manage- 
ment systems speed coding, they also shorten re- 
placement time considerably. That assumption 
has proved to be true, but not quite as we antici- 

ated. Many applications can be re-coded in 
ee two months time—but the overall elapsed 
time is often much longer than that. 


Why does replacement take longer than ex- 
pected? For one thing, when using prototyping, 
much experimentation takes place, as users try 
out new features. To give users time to test out 
the basic replacement system (and new features 
as they are added), replacement projects are of- 
ten scheduled as part-time activities for several 
people. Therefore, applications are generally not 
replaced in a short, full-time effort, but rather 
through a more drawn-out part-time process. 
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Another reason it takes longer than expected 
is that there is almost always little or no useful 
documentation of the old system. Even the code 
is often difficult to understand in old applica- 
tions, especially if a ‘bowl of spaghetti’ control 
structure has evolved. So replacement is gener- 
ally not a case of copying old code line-for-line. 
Quite a bit of analysis is needed to first under- 
stand the old system, find out what changes users 
want, and then prototype a new system that in- 
corporates the new, desired features. Also, time 
is needed for analysis, for testing the code, and 
for testing the interfaces to other applications. 
Creating the new system can take longer than 
expected. 

Also, we gather that companies do not have 
guidelines for prototype development using ap- 
plication generators, since the concept is so new. 
Thus, there could be wasted efforts. For exam- 
ple, too little time may be spent designing the 
database structure, so it must be redone several 
times. Refining parts of the system is inherent in 
the prototyping process, but some rework may 
become unnecessary with more forethought. 

Therefore, a program of planned replacement 
should have some guidelines that make proto- 
type development more efficient, and some tools 
to help the developers unravel old systems as 
well. 

While replacement with these new tools is 
faster than with conventional methods, it does 
not happen ‘overnight.’ However, it is important 
to note that ease of coding and ease of making 
changes, to data structures and program code, 
allow companies to now consider replacing ap- 
plications which they would hesitate to replace 
with conventional programming methods. 

And there is another factor to consider: The 
longer that replacement of old application sys- 
tems is delayed, the worse the maintenance 
problem will get for such systems. 


The new tools are inappropriate for our appli- 
cations. Many argue that application generators 
and data management systems are only appropri- 
ate for smaller applications; they cannot be used 
to replace the complex code in their older appli- 
cations. Martin, and others we have talked with, 
say this is just not true. Most functions in busi- 
ness applications that can be programmed in CO- 
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BOL can also be programmed in these newer lan- 
guages. 

To illustrate this point, Martin gives an exam- 
ple of a medium-size bank which had about 452 
COBOL programs a few years ago. After studying 
these programs, Martin stated that if those appli- 
cations were being developed today, rather than 
in the early 1970s, the bank would need only 25 
COBOL programs. Most of the remaining pro- 

rams could be coded using a combination of: 
1) a database management system that contains 
an application generator, a report generator, and 
a query language, and (2) purchased packages. 
The bank’s systems which were appropriate for 
these approaches included account checking, do- 
mestic savings, trust accounting, domestic loans, 
domestic mortgage, general ledger, and others, 
says Martin. 


Several other applications could be moved off 
the mainframe onto a mini-computer with a 
DMS, says Martin, further reducing their depen- 
dence on hand-coding. In this category, he in- 
cludes their systems for credit and collection, 
safe deposits registration, cable and mail control, 
and stationery and supplies control. 


Looking at business applications from a 
slightly different view, Martin places them into 
five categories. (1) Small application programs 
that are less than 2000 lines of basic assembly 
language code. About 70% of most organiza- 
tions’ business application programs fall into this 
category, he says. (2) Small-to-medium size ap- 
plication programs that range from 2000 to 16,- 
000 lines of code. About 20% of most organiza- 
tions’ business applications fit here, he states. (3) 
And medium programs that range from 16,000 
to 64,000 lines. Only 6% of most organizations’ 
programs are this large. So the great majority of 
business applications fit within the lower two 
categories (less than 16,000 lines of code), says 
Martin, and the 64,000 limit covers 96% of all 
programs. 


The top two categories—(4) large and (5) su- 
per-large—contain programs written mainly by 
software houses and computer manufacturers. 
They account for only 4% of the business appli- 
cations of most organizations. Martin believes 
they should be purchased packages rather than 
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written in-house, because they are so large and 
complex. 


Using these classifications, Martin says that 
application generators can be used in small and 
small-to-medium size applications—which ac- 
count for about 90% of most organizations’ busi- 
ness applications. For those applications which 
contain complex logic, procedural language rou- 
tines can be hand-written and combined with the 
generated code. In addition, to take advantage of 
database management systems for these applica- 
tions, prior database designing and planning is 
needed. 


However, it is fair to say that not all old ap- 
plications should be replaced with these new 
tools. On-line production systems, in particular, 
which handle large volumes of transactions, may 
not be appropriate if performance is a crucial 
factor in their usefulness. 


As mentioned earlier, applications which 
should be considered for replacement using 
these new tools are those with frequently chang- 
ing needs, where ad hoc reporting is important, 
and where users want to replace a batch system 
with an on-line information system. 


In conclusion, we suggest that companies look 
at the three types of tools discussed, with an eye 
toward replacing old applications. Maintenance 
costs are often way out-of-hand. Companies need 


to start chipping away at the sources of this 
problem. One way is to begin replacing some of 
the more obsolete and burdensome programs, 
and train new programmers in the new develop- 
ment methods at the same time. 
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COMMENTARY 


This month, our Commentary is a selective listing of data manage- 
ment systems and application and program generators for mainfra- 
mes, minis, and micro-computers. A number of these products can 
be used by employees who have no programming experience, to do 
their own programming. Where no specific type of mainframe or 
mini-computer is specified, generally such products are written in 
ANS COBOL. We have been compiling and updating this listing 
for several years; while we believe the list is accurate, some 
changes may have occurred of which we are not aware. 


ACEP, Software Module Marketing, 1007 7th St., Sacramento, 
California 95814. For IBM computers. Tel: 916-441-7234. 


ADF, DMS, QUERY BY EXAMPLE, GIS, and System 38 facili- 
ties, contact IBM at your local sales office. For their various com- 
puters. 


ADF/ASDM, M. Bryce and Associates, Inc., 1248 Springfield 
Pike, Cincinnati, Ohio 45215. For mainframe and some mini com- 
puters. Tel: 513-761-8400. 


ADS and ON-LINE ENGLISH, Cullinet Software, Inc. (for- 
merly Cullinane Database Systems, Inc.) 400 Blue Hill Dr., West- 
wood, Massachusetts 02090. For mainframe computers. Tel: 617- 
329-7700. 


AIMS 3, Aims Plus, P. O. Box 17247, Austin, Texas 78760. For 
Wang computers. Tel: 512-385-0702. 


ALL and ENGLISH, Microdata, 17481 Red Hill Ave., Irvine, 
California 92705. For their systems. Tel: 714-540-6730. 


ANSWER/DB, INQUIRY, IV/IMS, and MARK V, Informatics 
General Corp., 21050 Vanowen St., Canoga Park, California 
91304. For mainframe computers. Tel: 213-716-1616. 


ASIST, Applications Software, Inc., 21515 Hawthorne Bivd., 
Torrance, California 90503. For mainframe computers. Tel: 213- 
540-0111. 


AUTOPILOT, Software Automation Inc., 1100 Business Park- 
way, Richardson, Texas 75081. For small machines. Tel: 214-231- 
9142. 


BASIS, Battelle Columbus Labs., 505 King Ave., Columbus, 
Ohio 43201. For CDC, Univac, IBM, and DEC systems. Tel: 614- 
424-5524. | 


BOP, Production Engineering Laboratory, Nth Sintef, N-7034 
Trondheim-Nth, Norway. Prototyping tool for factory management 
systems. Tel: 075-93-800. 


CENTRAL SOFTWARE, Planning Research Corporation, 1500 
Planning Research Drive, McLean, Virginia 22102. Tel: 703-556- 
2200. 


COBGEN, Software Info Services, Inc., 3600 Wilshire Blvd., 
Suite 1510, Los Angeles, California 90010. COBOL program gen- 
erator for IBM OS and DOS systems. Tel: 213-380-0466. 


COGEN, from: (1) Bytek, 1714 Solano Ave., Berkeley, California 
94707, for any Ryan-McFarland COBOL system; and (2) Key Mi- 
crosystems Inc., 822 Boylston St., Chestnut Hill, Massachusetts 
02167, for micro-computers using CP/M 80 and 86, and MP/M 80 
and 86. 
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CPG, Insac Software Inc., 2300 Peachford Road, Atlanta, Geor- 
gia 30338. For IBM mainframe computers. Tel: 404-452-7676. 


CREATE, Complete Computer Systems, 159 Gibralter Road, 
Horsham, Pennsylvania 19044. For Data General systems. Tel: 215- 
441-4200. 


CUPID, Time Utilising Business Systems, 30 New Walk, Leices- 
ter, United Kingdom. For PDP-1l1s. 


DATASCAN, Data Management Systems Inc., 4360 Georgetown 
Square, No. 809, Atlanta, Georgia 30338. For IBM System 34 and 
Datapoint computers. 


DATATRIEVE, Digital Equipment Corporation, 100 Main St., 
Maynard, Massachusetts. For their equipment. Tel: 617-897-5111. 


dBASE II, Ashton-Tate, 9929 W. Jefferson Blvd., Culver City, 
California 90230. For 8-bit CP/M systems. Tel: 213-204-5570. 


DRB Program Generator, David R. Black and Associates, 1780 
Maple Ave., Northfield, Illinois 60093. For a number of mainframe 
and mini-computer systems. Tel: 312-441-8122. 


EASYTRIEVE and OWL, Pansophic Systems Inc., 709 Enter- 
prise Drive, Oak Brook, Hlinois 60521. For mainframe systems. 
Tel: 800-323-7335. 


FIRST, Data General Corp., 400 Computer Dr., Westboro, Mas- 
sachusetts 01580. For their computers. Tel: 617-366-8911. 


FOCUS, Information Builders, 1250 Broadway, New York, New 
York 10001. For mainframes and on time-sharing services. Tel: 
212-736-4433. 


FOUNDATION, Applied Data Research, Route 206 at Orchard 
Road, Princeton, New Jersey 08540. For mainframes. Tel: 201-874- 
9100. 


GENASYS, Genasys International Inc., 17 East 45th St., New 
York, New York 10017. For mainframe computers. Tel: 212-687- 
2015. 


GENERATION FIVE, American Management Systems, Inc., 
1515 Wilson Blvd., Arlington, Virginia 22207. For IBM and DEC 
systems; to be used in combination with their application pack- 
ages. Tel: 703-841-6000. 


HERO, The Software Authority, 1270 Oakmead Parkway, 
Sunnyvale, California 94086. For IBM-compatible mainframes. 
Tel: 408-749-9100n 


IFM and INFORM, United Computing Systems Inc., P. O. Box 
8551, Kansas City, Missouri 64114. Available on their time-sharing 
service, 


INFO, Henco, Inc., 35 Walnut St., Wellesley, Massachusetts 
02181. For IBM, Honeywell, and Prime systems. Tel: 617-237- 
4156. 


INFORMATION, Prime Computers, Prime Park, Natick, Mas- 
sachusetts 01760. For Prime equipment. Tel: 617-658-8000. 


INGRES and MicroINGRES. Relational Technology, Inc., 2855 
Telegraph Road, Suite 312, Berkeley, California 94705. INGRES 
runs on DEC VAX computers, and MicroINGRES is available for 
some micros using the Motorola MC68000 processor. Tel: 415- 
845-1700. 
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INQUIRE and IQ/NET, Infodata, 5205 Leesburg Pike, Falls — 


Church, Virginia 22041. For IBM equipment. Tel: 800-336-4939. 


INSYTE, Response Technology, Inc., 4064 South West Dono- 
van, Seattle, Washington 98101). For large Burroughs machines. 
Tel: 206-937-7845. | 


LINK, Burroughs. Corporation, One Burroughs Place, Detroit, 
Michigan 48232. For their machines. Tel: 313-972-7350. 


MANAGE, Computer Sciences Corporation, 650 N. Sepulveda 
Blvd., El Segundo, California 90245. Available through their In- 
fonet time-sharing service. Tel: 213-615-0311. 


MANTIS, Cincom Systems Inc., 2300 Montana Ave., Cincinnati, 
Ohio 45211. For mainframe systems. Tel: 800-543-3010. 


MAPPER and ESCORT, Sperry Corp. Box 500, Blue Bell, Penn- 
sylvania 19424. For Univac machines. Tel: 215-542-4211. 


MARS, J and S Associates, 1345 Wiley, Schaumburg, Illinois 
60172. For Honeywell DPS 6 mini-computers. Tel: 312-882-2878. 


MDBS III, Micro Data Base Systems, Inc., Box 248, Lafayette, 
Indiana 47902. For 8- and 16-bit micros, CP/M and other operat- 
ing systems, plus PDP-11 under UNIX or RSX-11M. Tel: 317-742- 
7388. 


MICRO AP, Micro AP, Inc., 7033 Village Parkway, Dublin, Cal- 
ifornia 94566. For micro-computers using the CP/M operating sys- 
tem. Tel: 415-828-6697. 


MIMS, GEISCO, One New England Executive Park, Burlington, 
Massachusetts 01803. Available through their time-sharing service. 
Tel: 617-273-1411. 


NATURAL, Software AG of N.A., 11800 Sunrise Valley Drive, 
Reston, Virginia 22091. For IBM mainframe systems. Tel: 703-860- 
5050. 


NOCODE, General Automation Inc., 1055 South Street, Ana- 
heim, California 92803. For their computers. Tel: 714-778-4800. . 


NOMAD2, National CSS, 187 Danbury Road, Wilton, Connecti- 
cut 06897. Available through their network. Tel: 203-762-2511. 


ORACLE, Relational Software Inc., 3000 Sand Hill Road, Menlo 
Park, California 94025. For IBM mainframes, DEC VAX, PDP-1], 
and LSI-11 (micro) computers. Tel: 415-854-7350. | 


PERSONAL PEARL, Computer Pathways Unlimited, 2151 
Davcor St. SE, Salem, Oregon 97302. For micro-computers using 
CP/M. TEL: 505-363-8929. 


PROGENI TOOLS, Progeni Systems Inc., 715 North Central 
Ave., Glendale, California 91203. For Burroughs systems. Tel: 213- 
956- 0251. 


QUESTOR, Comshare Inc., 3001 S. State St., Ann Arbor, Michi- 
gan 48106. Tel: 313-994-4800. 


QUIC-N-EASI, Standard MicroSystems, 136 Granite Hill Court, 
Langhorne, Pennsylvania 19047. For micros using CP/M. Tel: 215- 
968-0689. 


RAMIS II, Mathematica Products Group, P. O. Box 2392, 
Princeton, New Jersey 08540. For IBM machines and on several 
time-sharing services. Tel: 609-799-2600. 
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READY CODE, Raytheon Computer Services, Wayside Road, 
Burlington, Massachusetts 01801. Available on their time- ‘sharing 
service. Tel: 617-272-9300. 


REVIEW, Covill Associates, 9528 Miramar Road, Suite 124, San 
Diego, California 92126. For Burroughs B7000/B6000 computers. 
Tel: 619-270-6340. 


SCORE, Software Design Associates, 260 Madison Ave., New 
York, New York 10016. For Univac and IBM aes Tel: 212- 
686-2032. 


SEQUITUR, Pacific Software Manufacturing Co., 2608 Righth 
Street, Berkeley, California 94710. For 16-bit micros. Tel: 415-540- 
5000. 


SMART, Cincinnati Data Systems, 4250 Creek Rd., Cincinnati, 
Ohio 45241. For mainframe systems. Tel: 513-891-6647. 


SPEED II, TOM: The Office Manager, P. O. Box 66596, Seattle, 
Washington 98166. For Wang VS and 2200 computers. Tel: 206- 
246-7022. 


SUPER ENGLISH IX, Automated Quill Inc., 3501 S. Corona 
St., Top Floor, Englewood, Colorado 80110. For Data General 
computers. 


SYSTEM-80, Phoenix Systems Inc., 1106 Ohio River Blvd., Se- 
wickley, Pennsylvania 15143. For mainframes, minis, micros. Tel: 
412-741-8330. : 


TAPS/80, Intel Systems Corporation, 12675 Research Blvd., 
Austin, Texas 78766; For mainframe systems. Tel: 512-258-5171. 


THE FORMULA, Dynamic Microprocessor Associates, 545 5th 
Ave., New York, New York 10001. For micro-computers. Tel: 212- 
687-7115. | 


THE LAST ONE, DJ ‘AI’ Systems Inc., (1) Station Road, Ilmin- 
ster, Somerset TA19 9BQ, England; tel: 04605-4117; (2) 2 Century 
Plaza, Suite 480, 2049 Century Park East, Los Angeles, California 
90067; tel: 213-203-0851. For CP/M micro-computers. 


THE TOOL, High Technology Software Products, 2201 N.E. 
63rd, Oklahoma City, Oklahoma 73113. For Apple II. Tel: 405- 
478-2105. 


UFO, Oxford Software Corp., 174 Boulevard St., Hasbrouck 
Heights, New Jersey 07604. For IBM computers. Tel: 800-631- 
1615. 


USER-BASE, UserWare International, 2235 Meyers Ave., Escon- 
dido, California 92025. A micro-computer version of USER-11 that 
runs under OASIS operating system on both 8-bit (Z80) and 16-bit 
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EXECUTIVE SUMMARY 


lnfoemation systems departments have become over-burdened with mainte- 
nance work. One of the causes of this discouraging situation is “easy migra- 
tion.’ Hardware has gradually been upgraded, but application software has 
not. Companies have dragged their old programs along with them—programs 
that are causing more than their share of misery, both to information systems 
people and to end users. 


There are now application development tools available that can aid infor- 
mation systems departments in replacing some of these old programs. Data 
management systems, application and program generators, ‘and application 
packages make replacement of some old applications feasible. Applications 
most appropriate for replacement are those which have constantly changing 
requirements, those where ad hoc reporting is important, and those where 
users want an on-line information system to replace their old batch process- 
ing system. | 


Data management systems generally have ‘a fourth generation language,’ a 
report writer, a screen formatter, and other utilities, all based around a data- 
base management system. These systems are intended for end users (for writ- 
ing simpler systems) as well as for programmers (for developing more com- 
plex systems). They speed coding, ease file creation, and encourage prototyp- 
ing. 

Application generators generate programs by using user-supplied parame- 
ters to direct processing of pre-coded routines. Two considerations are im- 
portant when evaluating generators. One, the generator and the new system 
need to be closely matched (as we discuss). And, two, the new system must 
be designed with the generator’s capabilities and limitations in mind (for rea- 
sons we discuss). 


Application packages are becoming increasingly ‘tailorable.’ Users often 
can select desired options and store them in a control table. In another ap- 
proach, one company’s packages are written using an application generator 
so that modifications can be made to enhance the packages, using the genera- 
tor. | 


Application development is changing; more automated tools are becoming 
available. Thus, we think it is time for companies to start an ‘old applica- 
tions replacement program.’ Information systems management will face resis- 
tance to the new methods. But this new program could train new program- 
mers in the new methods and reduce the maintenance burden as well. 
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